<p>Controlling permissions is security-sensitive. It has led in the past to the following vulnerabilities:</p>
<ul>
  <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12999">CVE-2018-12999</a> </li>
  <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10285">CVE-2018-10285</a> </li>
  <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7455">CVE-2017-7455</a> </li>
</ul>
<p>Attackers can only damage what they have access to. Thus limiting their access is a good way to prevent them from wreaking havoc, but it has to be
done properly.</p>
<p>This rule flags code that controls the access to resources and actions. The goal is to guide security code reviews.</p>
<p>More specifically it will raise issues on the following Spring code:</p>
<ul>
  <li> The definition of any class implementing interfaces </li>
</ul>
<p> <strong></strong> <code>org.springframework.security.access.AccessDecisionVoter</code></p>
<p> <strong></strong> <code>org.springframework.security.access.AccessDecisionManager</code></p>
<p> <strong></strong> <code>org.springframework.security.access.AfterInvocationProvider</code></p>
<p> <strong></strong> <code>org.springframework.security.access.PermissionEvaluator</code></p>
<p> <strong></strong> <code>org.springframework.security.access.expression.SecurityExpressionOperations</code></p>
<p> <strong></strong> <code>org.springframework.security.access.expression.method.MethodSecurityExpressionHandler</code></p>
<p> <strong></strong> <code>org.springframework.security.core.GrantedAuthority</code></p>
<p> <strong></strong> <code>org.springframework.security.acls.model.PermissionGrantingStrategy</code></p>
<ul>
  <li> The definition of any class extending class </li>
</ul>
<p> <strong></strong> <code>org.springframework.security.config.annotation.method.configuration.GlobalMethodSecurityConfiguration</code></p>
<ul>
  <li> Any method annotated with </li>
</ul>
<p> <strong></strong> Pre-post annotations: <code>@PreAuthorize</code>, <code>@PreFilter</code>, <code>@PostAuthorize</code> or
<code>@PostFilter</code> from <code>org.springframework.security.access.prepost</code> package.</p>
<p> <strong></strong> <code>@org.springframework.security.access.annotation.Secured</code></p>
<ul>
  <li> Calls to any of the following methods </li>
</ul>
<p> <strong></strong> <code>org.springframework.security.acls.model.MutableAclService</code>: <code>createAcl</code>, <code>deleteAcl</code>,
<code>updateAcl</code></p>
<p> <strong></strong> <code>org.springframework.security.config.annotation.web.builders.HttpSecurity</code>: <code>authorizeRequests</code></p>
<ul>
  <li> The instantiation of an anonymous class implementing <code>org.springframework.security.core.GrantedAuthority</code> or of any class
  implementing this interface directly. </li>
</ul>
<p>It will also raise issue on JSR-250 annotations <code>@RolesAllowed</code>, <code>@PermitAll</code> and <code>@DenyAll</code> from
<code>javax.annotation.security</code> package.</p>
<h2>Ask Yourself Whether</h2>
<ul>
  <li> Granted permission to an entity (user, application) allow access to information or functionalities not needed by this entity. </li>
  <li> Privileges are easily acquired (eg: based on the location of the user, type of device used, defined by third parties, does not require approval
  ...). </li>
  <li> Inherited permission, default permission, no privileges (eg: anonymous user) is authorized to access to a protected resource. </li>
</ul>
<p>There is a risk if you answered yes to any of those questions.</p>
<h2>Recommended Secure Coding Practices</h2>
<p>At minimum, an access control system should:</p>
<ul>
  <li> Use a well-defined access control model like <a href="https://en.wikipedia.org/wiki/Role-based_access_control">RBAC</a> or <a
  href="https://en.wikipedia.org/wiki/Access-control_list">ACL</a>. </li>
  <li> Entities' permissions should be reviewed regularly to remove permissions that are no longer needed. </li>
  <li> Respect <a href="https://en.wikipedia.org/wiki/Principle_of_least_privilege">the principle of least privilege</a> ("_an entity has access only
  the information and resources that are necessary for its legitimate purpose_"). </li>
</ul>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control">OWASP Top 10 2017 Category A5</a> - Boken Access Control </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/276.html">MITRE, CWE-276</a> - Incorrect Default Permissions </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/732.html">MITRE, CWE-732</a> - Incorrect Permission Assignment for Critical Resource </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/668.html">MITRE, CWE-668</a> - Exposure of Resource to Wrong Sphere </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/277.html">MITRE, CWE-277</a> - Insecure Inherited Permissions </li>
</ul>

